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(57) Abstract: The invented system 
provides for construction, requesting, 
obtaining and using previews of Usenet 
multimedia objects in order to make 
informed downloading decisions. Selection 
and downloading of Usenet images is 
made fast and easy when image indexes 
in a format disclosed in this invention 
are available. Each such index contains 
an image and an image map that is a 
set of records associating image regions 
with particular UseneL articles. This map 
enables unique identification of the article 
that user wants when they click on a 
particular area of the index image. T he user 
client (newsreader) can then automatically 
find and start downloading the desired 
run tele. If an advertising banner is included 
in the image, the system can direct usc:r to 
the advertised web site and allows counting 
visits generated by such banners. Cf a 
multimedia objects preview is nor found 
in the newsgroup, users can send an index 
request to an index server. The server 
will download relevant articles, construe* 
previews and either post them to the Usenet 
or return to the requesting user, or both. 
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A Method and System for Interactive Work with 
Multimedia Objects Posted on the Usenet 

1 Field of Invention 

The present invention relates to Internet information services. In particular, the present invention relates to 
improvements in use of the Usenet 

In the first aspect, the present invention relates to helping Usenet users make informed decisions on whether they 
want to download a particular Usenet message. 

In the second aspect, the present invention relates to helping Usenet users to obtain information that is necessary 
to make informed decisions on whether they want to download a particular Usenet article. It describes a method 
and system allowing users to request small descriptions of large multimedia objects available for downloading. 
After previewing the description, users can make a decision on whether they want to download the objects it 
describes. 

In the third and fourth aspects, this invention relates to advertising on the Usenet It describes a method and 
system allowing inserting and using advertisement banners in Usenet messages and counting number of referred 
visits produced by a particular advertisement object. 



2 Background 

The Usenet is a worldwide bulletin board system that can be accessed through the Internet or through many 
online services. The Usenet contains tens of thousands of forums, called newsgroups, that cover many and varied 
interest groups. The Usenet is used daily by millions of people around the world. 

Every Usenet message belongs to a newsgroup. Messages are made available to users worldwide by means of the 
UUCP and NNTP protocols (Unix to Unix Copy Program, and Network News Transport Protocol, respectively). 
Individual computing sites oversee the huge quantity of incoming messages, and decide how long messages can 
be kept before they must be removed to make room for new ones. Typically, messages are stored for less than a 
week. They are made available to users via a news server. 

Users access local newsgroups with a newsreader program. Modern WWW browsers come with a built-in 
newsreader. A dedicated newsreader program can also be used. The newsreader accesses the local (or remote) 
News host using the NNTP, enabling a user to download as many newsgroups and their contents as they desire. 
If there is no local access to a news server, there are publicly accessible commercial and free Usenet hosts that 
can be accessed. 

Users sending Usenet messages must address each message to a particular newsgroup. There are newsgroups on 
subjects ranging from education for the disabled to Star Trek and from environment science to politics in the 
former Soviet Union. The quality of the discussion in newsgroups may be excellent, but this is not guaranteed. 
Some newsgroups have a moderator who scans the messages for the group and decides which ones are 
appropriate for distribution. 

Some of the newsgroups provide a useful source of information and help on technical topics. Users needing to 
find out about a subject often send questions to the appropriate newsgroup, and an expert somewhere in the world 
can often provide an answer. Lists of Frequently Asked Questions (FAQs) are compiled and made available 
periodically in some newsgroups. 

The Usenet was originally designed for exchange of textual information, but presently the major part of 
bandwidth and storage resources is consumed by so called "binary" newsgroups that mainly carry binary data. It 
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has been estimated that, in terms of bytes, the top four newsgroups consume 22% of the entire volume. The top 
35 groups consume 50% of the entire volume. 

Currently, almost the only description of a message is its subject This way of describing information items is 
more or less adequate for textual messages that contain text discussing the subject. For multimedia items, one- 
line descriptions can hardly be adequate. Normally, subject contains name of the collection or short description 
of the multimedia item, name of file, number of the part and total number of parts (such as "Persian kitten 
catsl23.jpg (1/1) 35567 bytes")- This format is often used, but many multimedia postings do not have even that. 
Often subject lines are quite meaningless, e.g. "My loved kittens". Figure 1 shows a list of Usenet messages in a 
binary newsgroup alt.binaries.pictures.animals. Figure 2 shows a so-called "index" of files posted in the group. 
Clearly, the way of representing of available contents as it is shown on the Figure 2, is much more user friendly 
and informative for users. 

Multimedia items, such as video, image, sound files, are bulky. It may take a minute to download an image over a 
slow modem line. For sound and video files, it may take several minutes and even hours to download them. This 
is why it is important to give users better means of selection, ensuring that they can make more informed 
downloading decisions and avoid wasting time and money on downloading large objects that will be discarded 
right a tier first viewing or hearing. 

-Indices" or "contact sheets" are often posted with large collections of images. It is a requirement of "netiquette" 
to post indices when posting a collection of images. Such indices give users a chance to preview pictures of the 
collection before downloading them and decide whether they want to spend their time and resources on 
downloading these images, and/or select images that they want to download. Often small picture previews (frame 
captures) arc posted with video files. 

However, working with such indices is very inconvenient Selecting and downloading desired files requires 
performing the following steps: 

Find and download the index (thumbnail preview). 

View the index. Identify file names of images represented by thumbnails. 
Memorise or write down file names of images to be downloaded. 
Locate messages that carry these files in the list of messages. 
Download the found messages, extract and save files. 

The system that we are inventing makes it very easy to achieve the same result. Users just download the index, 
view it, point to thumbnails of images that they desire to download and double click on the thumbnails to 
download related images or video files. We are inventing a way of use of index images that provides an easy, 
intuitive and efficient "point and click 9 ' interface for selecting and downloading multimedia items posted on the 

Usenet. 

There are systems that offer to end users similar options to what we are targeting. There are sites on the Web that 
load binary files from the Usenet to their proprietary databases, create preview items (thumbnails for images, for 
example), and then give access to the contents of these databases in WYSIWYG mode using Web browsers. This 
is not what we are targeting. We are targeting a system that can give users an easy and convenient way of 
previewing and selecting multimedia items using a newsreader and working with a standard news server. 

There are some patent applications targeting the same problem. A US Patent Application No 09/722676 with title 
"A Method and System for Communication in the Usenet" has been filed in 2000 by CSIRO Australia. In one of 
its aspects, the application describes a method and system for helping Usenet users to make informed decisions 
regarding downloading of multimedia items from the Usenet. In particular, the described application invents a 
method that allows to post metadata items associated with multimedia items, present these items for user preview, 
then locate and download multimedia items selected by the user based on the presented metadata items. 

When used with image collections, this system allows to post small image thumbnails associated with messages 
that carry the image files, present these thumbnails to users for preview, then when users select one or more of 
the images for downloading, locate the needed messages and download them. 

.2. 
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However, the invention disclosed in CSIRO application has 3 disadvantages that the present invention aims to 
eliminate. 

1. It requires insertion of association information (tags) to headers of messages being posted. When such 
tags are automatically inserted in messages subjects, they make subjects look somewhat aesthetically 
unpleasing. 

2. As a consequence of the requirement to insert tags in the messages headers, metadata items can only be 
posted with a new collection, by the software that generates and posts the messages. It is not possible to 
add metadata descriptions to a collection that has been already posted without them. 

3. Images thumbnails are posted in a format that can't be used by newsreaders that are not specifically 
designed to work with this format, even if they can show images. 

The present invention eliminates the disadvantages listed above. It does not require insertion of any 
additional/special information in messages carrying multimedia items. It enables adding metadata descriptions to 
collections that have been posted already by same poster or different people. And finally, it posts images 
thumbnails as standard indices (or contact sheets) commonly posted by Usenet users. The system includes 
additional information that allows associate thumbnails with messages that carry the actual images or videos. 

Unfortunately, not everyone observes requirements of the etiquette. Many collections of images are posted 
without indices.. There are groups where indices are rare. Video files are also very rarely posted with previews. 
Sometimes people help each other and previews are posted later, not by the person who posted the original 
articles, but by someone else who downloads them, builds previews and posts them for other people to use. 

The system that we are inventing (the second aspect) makes it possible for Usenet users to request 
indices/previews for a particular set of articles. They send such requests to one or more servers that specialise in 
processing of such requests (index servers). These servers can be co-located with news servers, so that usage of 
Internet bandwidth required to build and post an index is minimal. 

There are systems that offer to end users similar options to what we are targeting. There are sites on the Web that 
load binary files from the Usenet to their proprietary databases, create preview items (thumbnails for images, for 
example), and then give access to the contents of these databases in WYSIWYG mode using Web browsers. This 
is not what we are targeting. In the invented system, anyone can request an index for a particular set of articles, 
provided they have access to an index server. The index server builds this index, possibly caches it, and posts it 
to the Usenet or sends it back to the user who requested it. If the index has been posted to the Usenet, it becomes 
available for everyone for previewing and selecting multimedia items using a newsreader and working with a 
standard news server. If the service is configured so that it sends indices to users who requested them, then the 
users can use obtained indices to make better informed decisions on whether to download a particular object from 
the Usenet. Either way, this invention makes it possible for Usenet users to obtain information that helps them to 
choose what they want to download. 

The third and fourth aspects of the present invention deal with advertising on the Usenet. The Usenet is being 
actively used for advertising. Many images and videos posted on the Usenet contain advertising references to 
Web sites. Many messages have URLs of advertised Web sites. However, unlike Web advertising, where users 
have just to point and click on a banner that attracts their attention, Usenet advertising is not as convenient to use. 
For example, if a URL is shown on an image posted on the Usenet, users have to re-type this URL in their 
browser to reach it. Needless to say that relatively few people go for so much trouble to visit an advertised site. 

Enabling "point and click" functionality in Usenet advertising would certainly increase number of people who 
respond to advertising because pointing to a banner or URL and clicking on it is much easier and simpler than re- 
typing a URL in a browser. The other reason is that it allows designing and using for advertising graphical 
"clickable" objects specifically targeted at catching users attention and encouraging them to click on the object. 

Another problem that the Usenet advertisement currently has is difficulty with counting referred visitors. 
Counting referred visitors is an important requirement in commercial advertising because advertising fees are 
often based on numbers of visits to the advertised Web site generated by the advertising. Counting such visits is 
relatively easy on the Web. For example, if site A is displaying banners advertising site B, it is not hard for site A 
to count user clicks on the advertising banners and thus the number of visitors referred to site B. 
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The situation is quite different in the Usenet environment. When users download Usenet messages, they are not 
in any contact with the party that has posted these messages. When users follow advertising and visit the 
advertised sites, no feedback of this activity is coming to the poster of the advertisement. 

The second aspect of this invention deals with advertisement on the Usenet. It discloses a system that makes it 
easy ("point and click") to follow advertisement links. It also discloses a system that provides for accurate 
counting of visits to the advertised site generated by an advertisement posted on the Usenet. 

3 Summary of Invention 
3.1 First Aspect 

A first aspect of the present invention provides a method of coordinating the identification of objects with their 
descriptions (metadata) in a newsgroup of the Usenet, the method including the steps of: 

generating a graphical index (contact sheet) of images or videos posted in Usenet messages, 

generating an image map of the graphical index that associates regions of the graphical index with Usenet 

messages, 

posting the message containing the graphical index and the image map. 

There is also provided a method of downloading messages from the Usenet, the method including the steps of: 

receiving headers or only XOVER information of messages available for downloading, 

scanning this received information to identify which messages contain graphical indices, 

downloading the messages containing graphical indices, 
> presenting the indices to the user to make a decision regarding the downloading of associated objects, 
£? if the user wants to download an associated object, 

locating the image map record that corresponds to the region of the index where the user mouse is pointing to, 
m finding and downloading the message that the map record refers to. 

It has been realised that images represent a significant part of multimedia objects posted on the Usenet. Users 
tr. posting large collections of images (tens or hundreds of them) often post indices - images that contain thumbnails 
& (small copies) of images posted in the collection or small copies of frames captured from video movies. This 

gives to the downloaders the opportunity to download first the index image and get a better idea about the images 

posted in the collection, make better informed decisions whether to download a particular image and thus save 

downloading time and money spent on the Internet session. 

This aspect of invention is based on an automatic way of providing a graphical index for every multimedia item 
posted in a collection and associating thumbnails in the index with messages that carry the items these thumbnails 
represent. 

This illustrates an approach that uses a different kind of description of an information item. Naturally, a little 
copy of image is a better description of it than a subject line. 

This allows users to save downloading time and makes easier and more efficient the process of selecting and 
downloading media items. To download a set of selected images from a posted collection, currently, the user 
may have to perform the following steps: 

locate collection messages; 
locate collection indices; 
download collection indices; 

view collection indices and memorize (or write down) names of wanted files; 

locate messages carrying the wanted files and either mark them for background downloading or download them 
instantly; 



4 



Bf JSDOCID- <WO 20O4O556S2A :.J„> 



WO 2004/055692 



PCT/AU2003/001668 



The present invention allows for establishing of connections between visible thumbnails in index images and 
messages containing the media objects that these thumbnails represent. The invention then uses these connections 
to identify and download media objects selected by the user. The user indicates their preferences preferably by 
pointing with their mouse pointer and clicking on thumbnails of objects that they want, when viewing the index 
image. 

The connection is established in two stages: first, the thumbnail region is associated with a record in a special 
image map contained in the index message. Second, the record in the image map is associated with the message 
that has the media object (or at least a part of it) that is represented by the thumbnail. 

The method of the first aspect preferably includes two stages. 

Stage 1 

A poster posts a collection of multimedia items. An index of the collection may be posted together with the 
collection or added later when the collection has been posted already. 

A collection index is a message or several messages that include images containing thumbnails representing the 
collection items, and image maps for each of the index images. An image map is a set of records, each of which 
contains some information about a particular region of the image. Thus, if a thumbnail occupies a region, the 
record may include information that relates to the thumbnail and the item represented by the thumbnail. Records 
arc associated with image regions by including in each record a set of coordinates that define a particular image 
region, as it is illustrated in Figure 3. 

To find a record corresponding to a particular point in the image, records in the image map are searched and 
those that have coordinates of regions that contain the given point are identified. 

Based on these records, the point then can be associated with a particular message or set of messages. 

There are different ways to indicate an association between records in image map and corresponding messages 
carrying the collection items. 

One of possible methods is described in the CSIRO patent application. It uses unique pairs of tags. One tag of the 
pair is included in the index message. Another tag of the pair is included in the header of the associated message. 
When the first tag is given, it is possible to construct the second tag and then find a message that has it in its 
headers. We described above the disadvantages that this method has. 

Therefore, we use two other methods to achieve the same result (establish references from the index messages to 
the messages that carry media objects described by the index), but in a better way. Generally, any combination of 
message header fields (preferably fields included in XOVER) can be used, as long as it uniquely identifies the 
messages. 

The first preferred method is used in a case when index with a new collection is posted. In this case no message- 
IDs of collection messages are available at the moment of posting. In this case, a pair <message subject, poster 
IE» is included in the image map record to identify the message the record refers to. It must be noted that some 
news servers return at the moment of posting message-IDs assigned to messages. Some other servers accept 
message-IDs generated by posting clients. Although it is possible to use these features, they can't be relied upon 
because they are not a part of NNTP. 

The second preferred method is used in a case when index is posted for a collection that has been posted already 
and is available in one or more Usenet newsgroups. In this case unique message-IDs are available for all 
collection messages and can be included in image map records to establish references. 

Stage 2 

The downloaded client downloads headers of all new messages in the newsgroup or just XOVER information, 
which is sufficient if we use the preferred methods described above. The client may identify the index messages 
and automatically download them and present to the user, or it may do it in response to some action of the user, 
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indicating that the user wants to see the index. For example, the user may have to click on the index message in 
the message list in order to see the index. 

At each point of time when the user moves their mouse pointer over the index image, the client receives mouse 
movement events and can track the pointer and is aware of the image region the pointer is in. When the user 
wishes to download/see a particular image/movie, they point to its thumbnail and do some action, e.g. double 
click or press enter key. The client determines the coordinates of the mouse pointer within the image and searches 
the image map for a region containing a point with these coordinates. 

When such a record is found, the client reads either < subject, poster ID> pair or message-ID from this record, 
looks for a message that has these attributes, downloads it and presents to the user or does any other action that 
user wants to be done with this message. 

The found message may contain only a part of the multimedia object wanted by the user, or be just an overview 
message. In such a case, messages that contain other parts of the object have similar subject that normally differ 
only by part numbers and are easy to locate. Modern binary newsreaders usually can do it automatically. 

The user may have a number of options to select from when dealing with a particular thumbnail. Downloading is 
not the only possibility. For example, they can insert the media item into a list for automatic background 
downloading, delete corresponding messages from the message list view the media item if it is already 
downloaded, etc. 

This approach has been found to significantly simplify for users the process of selecting and downloading of 
multimedia items. For example, in case of images, user sees a set of small images (thumbnails) presented by the 
newsreader. Each of these images represents a "real" large image. To download real images, the user just has to 
double click on a thumbnail or select a few of them and then start batch downloading. 

. {■ 

^ Although this kind of 'click on link' interaction is used on the Web, but the underlying protocol (HTTP) is 
^different. Our invention makes it possible to achieve the same level of convenience when working with the 
Usenet-like systems. 

> 

&The advantages of the present invention include: 

3£ ]) A better representation of available messages during selection stage. This avoids downloading 
multimedia objects that are unwanted and will be discarded later anyway. 

2) An index that is viewable in other newsreaders. Most newsreaders provide a way to view images 
attached to messages. Even if a newsreader is not designed to use image maps and locate referred 
messages automatically, the user still can use the index image to select and download wanted 
messages, although not as efficiently as this invention makes it possible. 

3) Indices can be posted not only with a new collection, but also for existing collections, that have 
already been posted, possibly by other people. 

4) This method has no effect on subject text or other fields of message headers. No ugly tags appear in 
headers. 

This invention provides a general, flexible and easily extensible way of associating of additional information with 
messages and using this information when required. 

3.2 Second Aspect 

A second aspect of the present invention provides a method and system for providing "indices on request" 
service to the Usenet users. 

The system includes a Usenet news server, a user client application (such as a newsreader) and an index server, 
all three components able to communicate with each other via network connections. 

The method includes the steps of: 

the user identifying a set of articles that they would like to be indexed; 
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the user submitting information identifying these articles to the index server; 

after receiving and accepting this request, the index server downloading these articles, constructing their 
previews (indices) if possible and either submitting these indices to the news server, or sending them back to the 
user client application, or both; 

optionally, the user downloading and viewing the constructed indices. 

This gives to the downloaders the opportunity to download first the preview (index) information and get a better 
idea about the multimedia items available for downloading, make better informed decisions whether to download 
a particular item and thus save downloading time and money spent on the Internet session. 

This invention minimises users efforts and expenses involved in publishing indices. All users have to do is to 
compose a list of articles carrying the multimedia items to be indexed and submit this list to an indexing server 
that takes care of retrieving the items, constructing their previews and publishing (posting) these previews on the 
news server. Because these two servers can be co-located, all the traffic involved in retrieval of bulky multimedia 
items from the news server in order to construct their previews, would be local. This insures that the system is 
efficient and economic. 

Once indices (previews) have been published and are available, they significantly decrease amounts of wasted 
time and resources spent on downloading of unwanted material. 

It is technically possible to implement completely automatic indexing of multimedia newsgroups, but the quality 
of service would be relatively low, for at least two following reasons: 

1. It is impossible to determine automatically whether a collection of items to be indexed is appropriate (on 
topic) for a particular newsgroup. Indexing inappropriate collections and advertising junk posts would 
constitute violation of Usenet etiquette because indices/previews of off-topic items would be also off-topic. 

2. In many cases, it is hard to determine automatically whether a collection already has an index included. 
Creating additional indices would lead to unjustified spending of Usenet resources. 

This invention also discloses a method for automatically identifying collections of images. 

33 Third Aspect 

A third aspect of the present invention provides a method of using images for advertisement on the Usenet, the 
method including the steps of: 

generating an image containing advertisement regions, 

generating an image map of the image that associates regions of the image with URLs of Web pages, 
posting the message containing the image and the image map. 
downloading the messages containing advertising images, 
presenting the images to the user to view, 

if the user wants to follow advertisement^ 
locating the image map record that corresponds to the region of the index where the user mouse is pointing to, 
accessing the URL, preferably using a Web browser, if a URL found in the image map record. 

The present invention allows for establishing of connection between image regions and URLs they are 
advertising. The invention then uses these connections to access URLs associated with image regions selected by 
the user. The user indicates their preferences preferably by pointing with their mouse pointer and clicking on 
advertising parts of the image. 

The connection between the advertising part of the image and the target Web site is established in two stages: 
first, the image region is associated with a record in me image map contained in the index message. Second, the 
record in the image map is associated with the Web page by including its URL. 
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The method of the second aspect preferably includes two stages. 
Stage 1 

Poster posts an advertising message. An advertising message contains an image containing graphical advertising 
and an image map of this image. An image map is a set of records, each of which contains some information 
about a particular region of the image. Thus, if a region is advertising a particular Web site, the record may 
include the URL of the site. Records are associated with image regions by including in each record a set of 
coordinates that define a particular image region. 

To find a record corresponding to a particular point in the image, image map records are searched and those that 
have coordinates of regions that contain the given point are identified. 

Based on these records, the point (or region) then can be associated with a particular URL. 

Stage 2 

The user client downloads an advertising message and presents the image contained in the message to the user. 

At each point of time when the user moves their mouse pointer over the index image, the client receives mouse 
movement events and can track the pointer and is aware of the image region the pointer is in. When the user 
wishes to follow a particular advertisement, they point to the region of the image that represents it and indicate 
their wish, e.g. double click or press a key. The client determines the coordinates of the mouse pointer within the 
image and searches the image map for a region containing a point with these coordinates. 

When such a record is found, the client initiates a sequence of actions leading to visiting the URL that is being 
advertised. 

JH&- The advantages of the present invention include the ease of accessing advertised sites. This will result in 
Mr significantly increased response to advertising efforts, i.e. number of visitors to advertised sites generated by 
S advertisement posted on the Usenet. 

Tr 3.2 Fourth Aspect 

£2 A fourth aspect of the present invention provides a method of counting visits to sites advertised on the Usenet, 
the method including the following steps: 

establishing a Web site or a script on a Web site, 

generating a URL that has a direct or indirect reference to the advertised site, 
posting the generated URL in advertisement messages, 

when a user accesses the URL, processing its parameters, increasing visitors count and referring the user to the 
advertised site. 

This method is based on use of a dedicated Web site or a script on a Web site to count visitors and refer users to 
advertised sites. We will call this site/script a "referring site" or "redirecting site". 

When a user accesses such an advertisement URL, their browser first comes to the referring site and passes to the 
referring script the parameters that identify the target (advertised) site. The script identifies the target site, 
increases the counter of visitors of this site and refers the browser to the target site. Referring a Web browser 
from one URL to another is not a problem and is routinely done on the Web. 

Examples or advertising URLs: http://sendmeto.con^goto?url=http://www.my site.com or 
http://sendmeto.com/goto?account=#42527829090 

In both of these examples, *sendmeto.com" is a referring site and "goto" is name of the script on this site that 
does counting and refers visitors to the target site. - 
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In the first example, the target URL is included in the advertising URL explicitly. In the second example, the 
target URL can be identified via the account (profile) number included in the advertising URL. The processing 
script has to find the account and get the target URL from there in order to refer the visitor. 

The present invention provides a way to establish accurate counting of visits generated by advertisements posted 
on the Usenet. 

4 Embodiment 
4.1 First Aspect 

A practical implementation of this invention does not require changing of involved standards, such as NNTP, 
MIME etc. It only requires modification of posting and downloading news clients so that they would add some 
extra information to messages carrying collection indices and could interpret this information during the 
downloading stage. 

To describe how the system works, we will take as a base work of Ozum newsreader, version 2.86 build 1107 
that has in-built functionality to automatically produce standard contact sheets (thumbnail sheets, indices) when 
posting collection of images. We will refer to this newsreader as "Ozum" in the text below. Those skilled in the 
art are familiar with use of a typical news client. We will describe how the improved client works in our 
embodiment. To do this, we will describe what it does differently or additionally to Ozum. 

For sake of simplifying this description, we will call OzuniPlus an improved Ozum newsreader with functionality 
disclosed in this invention. 

The format of index messages generated by OzumPIus has to be such that when a user clicks or double clicks on 
any thumbnail within the index image, the information included in the index message would allow identifying the 
related message (for a thumbnail). This can be achieved by including an image map in the index message, as 
Figure 3 illustrates it. 

When posting indices with new collections or posting indices for collections that have been posted already, 
OzumPIus has to generate indices as Ozum does it now, plus include this additional information. 

4,1.1 Format of Index Messages 

Index messages include index images and their image maps (preferably placeU after the image). An image map is 
preferably a set of lines defining associations between image regions (preferably rectangles) and messages that 
carry media items represented by the thumbnails or URLs corresponding to the banners. Image map preferably 
starts with a line containing a string: <image_map>\r\n and ends with a line containing a string </image_map>. 
Any other distinctive strings can be used as long as they are unlikely to occur in messages that don't have image 
maps. 

For every thumbnail, the image map includes a line in format similar to standard (Web, HTML) image map 
format: 

rect «message identification info> crc=<crO size=<size» coordinates 
Where 

rect - is a method name, serving for conceptual compatibility with image maps and for possible later extensions. 

message identification info - is either message id of the message referred by the map line, or <subject, poster ED> 
pair. It is best to use message ids for purpose of identifying messages, but they are not available, for example, 
when we are posting a new collection and want to post indices with it. In this case <subject, poster IE» pair has 
to be used and file name or number included in the subject in order to ensure uniqueness of subjects within the 
collection. 
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coordinates - preferably left top and right bottom coordinates of the rectangle in the index image occupied by the 
thumbnail. Clicking (or double clicking) in this rectangular area of the image will cause downloading of the 
associated message. Although rectangular areas are used in this embodiment, other shapes can be used too. 

crc and size are optional fields for the purpose of this invention, and can be used to determine that an identical 
object has been downloaded by this newsreader in the past, or for any other purposes, such as verification of 
correctness of downloading and decoding. 

If index image is large and is split in several parts when posting, a full image map is preferably posted with every 
part. 

4.1.2 Algorithms 

4.1.2.1 Posting Indices with a New Collection 

Creating indices happens when people send indices with new collections. Message ids are not available at the 
time of posting, so, other information, less reliable than message ids, must be used. 

OzumPlus creates and posts index as Ozum does it, except: 

For every thumbnail put an entry in the image map containing the thumbnail rectangle coordinates and <subject, 
poster> pair preferably in format: 

rect <subject=subject text '\t' poster=poster text crc=<crc> size=<size» coordinates 

Here '\t' is a tab character. It can not occur in subject or poster text and therefore is convenient for use as a. 
^separator. 

' * 
m 4. 1.2.2 Adding Indices to an Existing Collection 

Adding indices happens when a user wants to add an index to a collection that has been posted already. In this 
case they select collection messages in the messages list, right-click on the selection and choose "Add Index" in 
—the context menu. 

- OzumPlus downloads the messages, extracts media items, creates and posts the indices. 

This case is similar to the case of posting indices with a new collection, except in case of adding indices, as 
opposed to the case of creating indices, message ids of indexed messages are available and can be used instead of 
their <subject, poster> pairs. Message ids are more reliable for messages identification and therefore preferable. 

So, the entries in image map are preferably in following format: 

rect <msgid=<msg-id> crc=<crO size=<size» coordinates 

4.1.2.4 Using Indices 

When user double clicks on a message containing an image, OzumPlus checks whether this message also 
contains an image map. 

If the image and/or image map are split into several parts and posted in several messages, OzumPlus downloads 
all the messages and assembles the image and/or the image map. This procedure is done routinely now by many 
newsreaders and does not represent a significant technical problem. 

OzumPlus reads the image map and verifies that it reads OK and all its parameters, such as coordinates of 
rectangles are in reasonable ranges. If not, the image map is ignored. 

If the image map is recognized, the regions that it defines in the image are treated as "clickable". OzumPlus reads 
the map and preferably stores its entries in a list in the memory before displaying the image. 
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When user moves their mouse pointer over the index image, OzumPlus receives and preferably processes mouse 
movement events in order to identify the image map entry that corresponds to the point over which the mouse 
pointer is. To do this, OzumPlus uses coordinates of the areas included in the image map entries. 

When the user puts the mouse pointer over some point in the image and does something, for example, presses a 
particular key or mouse button, OzumPlus does the following 

1. If there is no image map entry identified for the point and the action requires such entry, do nothing. 

2. If there is an entry found for this point, identify the message based on the information available in the 
entry and perform the function corresponding to the action done by the user. For example, if the user 
double clicks, download the message and present it to the user. 

A preferable scenario of using index images and image maps is described below. 

OzumPlus displays the index image and traces mouse movement over the image. When a click or double-click 
event comes and the mouse pointer is over a rectangle defined in the image map: 

1. If the rectangle corresponds to a thumbnail and the event is a single left mouse button click, use 
message-ID or <subject, poster> pair that provided in the image map to identify the message and: 

a. If the message is marked for downloading — unmark it. 

b. If the message is not marked — mark it. 

c. If the message is downloaded or not available — do nothing. 

d. If the message is not marked and, based on crc and size, it is clear that this message has been 
downloaded before — display a dialog asking for downloading confirmation. 

2. If the rectangle corresponds to a thumbnail and the event is a double left mouse button click — use 
message-ID or <subject, poster> pair that provided in the image map to identify the message and 
download and display the message. 

3. If the event is a double right click - do nothing. 

4. If the event is a single right click - display a menu with the following options: 

a. Mark to Download (disabled if the message is marked already); 

b. Unmark (disabled if the message is not marked); 

c. Download Now (disabled if the message is downloaded or not available); 

d. Mark as Read; 

e. Select (add to a list of currently selected messages in the group list). 

5. After the user chooses any of the actions available from the menu use message-ID or <subject, poster> 
pair that provided in the image map to identify the message, then perform on it the action requested by 
the user. 

4.2 Second Aspect 

A practical implementation of this invention involves implementing the client side and the server side. 
Functions preformed by the client side: 

1. Allowing the user to provide address and authentication information necessary to connect and interact with 
the index server. 

2. Allowing the user to browse articles available for downloading from the news server. 

3. Allowing the user to select a number of articles and indicate that an index (preview) is to be built for items 
carried by these articles. 

4. Allowing, the user to input parameters of indexing. For image indices such parameters are numbers of 
columns and rows of thumbnails on page, size of thumbnails, etc. 

5. Forming text of the index request. 

6. Connecting to the index server and sending the index request there. 
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7. Presenting the server's response to the user. 

To describe how the system works, we will take as a base work of Ozum newsreader, version 2.87 build 1111 
that has in-built functionality to produce standard contact sheets (thumbnail sheets, indices) for images available 
for downloading. We will refer to this newsreader as "Ozum" in the text below. 

Those skilled in the art are familiar with use of a typical news client. We will describe how the improved client 
works in our embodiment. To do this, we will describe what it does differently or additionally to Ozum. For sake 
of simplifying this description, we will call OzumPlus an improved Ozum newsreader with the user client 
functionality disclosed in this invention. 

Using Ozum, it is possible to select a number of articles and order Ozum to download these articles, build index 
of images carried by these articles, and post this index back to the news server. Thus, Ozum provides an easy way 
for adding missing previews to collections of images. The disadvantage of this method is that the user who orders 
indexing cannot benefit from it because building of indices requires downloading of all articles that are being 
indexed. So, by the time the index is ready and published on the news server, all the indexed items are 
downloaded and stored on the computer of the user who ordered indexing. 

Other users, however, can use the newly added index to choose articles that they want to download. Ozum can be 
modified to not to create indices locally, but instead form and submit an indexing request to an index server. 

To implement the required functionality, the following modifications can be implemented: 

1. An additional "Index Server Properties" dialog allowing users to input index server address, port number and 
authentication information (user name and password). 

2. The functions that create index have to be modified so that after indexing job has been formed ("Create 
Index" menu option in Ozum), OzumPlus submits the list of articles and job parameters to the index server 
in a certain format discussed below. After submission, OzumPlus receives response from the server and 

tm. reports to the user whether the index order has been accepted or there is a problem. 

Both modifications are not hard to implement for those skilled in the art. An extended subset of NNTP 
commands can be used for communications between OzumPlus and index servers. This set includes standard 
NNTP commands AUTHINFO USER, AUTTCNFO PATH and QUIT. An additional X1NDEX command is 
introduced that, when issued by the client, asks the server to accept an index order information. The server either 
agrees to receive it or rejects. This works similar to the NNTP POST command. 

Example 1. 

Client: XINDEX 

Server: 340 OK, send your data. 

Client: <.. . Request data followed by a line containing a single dot> 
Server: 240 request accepted. 

Example 2. 
Client: XINDEX 

Server: 440 Sorry, too busy, accepting new requests is temporarily suspended. , * 

Example 3. 

Client: XINDEX 

Server: 340 OK, send your data. 

Client: <. . . Request data followed by a line <x>ntaining a single dot.> 
Server: 441 request rejected, bad request data. 

Index request data contains a list of articles to index and all other information that is necessary to build indices, 
such as attributes if fonts used, size of thumbnails, etc. XML-like encoding can be used to encode request data 
and send it to index server. Such encoding allows easily extracting data items from the request text, using 
available XML software to do that, and also adding new types of items to requests if necessary. 

Example of encoded request data: 
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<header text="This is index header text." font="Arial M size="18" style= w bold M > 

<footer text="This is index footer text." font="Georgia" size="14" style="boIditalic"> 

<captions font="Arial Narrow" size="I0"> 

<thumbnails size="100" rows="3" columns= n 6"> 

<newsgroup name="alt.binaries.multimedia"> 

<message-ids> 

hdsghskl653j@newsxompany.com 12325426 
hdsghskl6534j@news.company.com 12325427 
hdsghskl6535j@news.company.com 12325428 
hdsghsk 1 653 8j @news.company .com 1 23 25429 

</message-ids> 



Articles numbers in the group on the server are preferably included in addition to textual message ids, for 
reliability of retrieval. Theoretically, articles numbers are not needed because news servers are supposed to be 
able to find and serve articles based on textual ids only. In practice, this does not always work. A server may 
respond that the article is unavailable when given a textual id, and yet successfully find it when given the number 
of the article in the group. 

Example of a complete session. 

Client connects to server. 

Server: 200 Hello, this is index server at mynews.com. 

Client: AUTHENFO USER joke 

Server: 381 user name OK, send password 

Client: AUTHINFO PASS notfunny 

Server: 281 authentication accepted 

Client: XINDEX 

Server: 340 OK, send your data. 

Client: <header text="This is index header text." font="Arial" size="18" style="bold"> 

<footer text="This is index footer text" font="Georgia" size= n 14" style="bo!ditalic"> 
<captions font=" Arial Narrow" size=" 1 0"> 
<thumbnails size="10" rows="3 M coiumns="6"> 
<newsgroup name="alt.binaries.miiltimedia ,! > 
<message-ids> 

hdsghsk 1 653j @news.company.com 
hdsghskl6534j@news.company.com 
hdsghsk 1 6535j@news.company.com 
hdsghskl6538j@news.company.com 

</message-ids> 

Server: 240 request accepted. 
Client: QUIT 

Server and client close the connection. 
Functions performed on the server side: 

1. Listening for incoming connection requests. 

2. Accepting connections, authenticating clients. 

3. Accepting or rejecting index requests. 

4. Performing index requests. 

The first three functions are trivial. Almost any server performs similar functions. The only difference is in 
request types. After receiving an index request, the server should check its format and check that values of all 
parameters are valid. 



12325426 
12325427 
12325428 
12325429 
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The system consisting of the client and server can be modified to work so that the created by the index server 
index is returned directly to the client, instead of, or in addition to, being posted to the Usenet. In this 
modification, the index server preferably maintains a cache of indices created by it, to optimise the performance. 

In case if produced indices are being posted to the Usenet, in addition to, or instead of, returning them to the 
requesting user, to avoid wasting of Usenet resources and ensure a higher quality of service, index servers should 
not repetitively post indices of articles that have been indexed already. For this purpose, index server can 
maintain a list of articles that have been indexed in the last few days. The server does not post indices of articles 
that are in the list of indexed or are too old (e.g. older than the oldest article in the list). 

It is harder to avoid repetitive indexing when there are many index servers run in parallel, possibly by different 
companies. In this case, one of them (let us call it "Server 1") can maintain a global list of indexed articles. Other 
servers, before posting an index, can connect to Server 1, send it a copy of the request (or just a list of articles to 
be indexed) in order to verify that articles that they are asked to index, have not been indexed yet by any of index 
servers. After receiving a verification request from another server, Server 1 checks the global list of indexed 
articles and replies whether the index should be posted. If the articles have not been indexed yet, it recommends 
posting of indices and adds the articles to the global list of indexed articles. 

It is also possible to avoid repetitive indexing and posting by introducing specialisation among index servers. 
F\ cry server is assigned a subset of Usenet newsgroups that it can index. It accepts only index requests 
concerning these newsgroups and rejects index requests involving indexing material from newsgroups outside of 
the assigned subset. 

After the index request has been verified and accepted, the index server that accepted it either finds ready indices 
in the cache, or downloads articles that it was asked to index, constructs indices or previews of attached 
multimedia objects and optionally posts these previews to a newsgroup where users can find them. It can be the 
original newsgroup(s) the articles were downloaded from, or it can be a special newsgroup dedicated to posting 
indices/previews of multimedia objects. 

It must be noted that index server and news server don't have to be separate instances. Index server functions can 
be built in into a news server. This system would be even more efficient than separate index server and news 
server. 

As it was noted above, newsgroups can be indexed completely automatically. That is. indices/previews of 
multimedia items are created scon after the items become available in the group. 

Constructing samples of video and audio material is relatively easy. Articles carrying all or just first few parts of 
the file must be downloaded, the file assembled and then samples/previews constructed by an applicable for this 
media type method. For example, for a video file, some frames can be extracted and converted to images, or a 
much shorter video file can be constructed from short video sequences taken from the original file. 

It is harder to achieve acceptable quality of indexing for images. There is no sense in indexing of individual 
images. To achieve an acceptable quality of service, only collections of images should be indexed. We invent a 
heuristic method for identifying posted collections of images for the purpose of indexing. A set of articles is 
determined to carry a collection of images if it satisfies to the following conditions: 

1. The articles have images attached. This is very likely if articles 1 subjects include file names with extensions 
of image types, such as .gif or .jpg. 

2. They were posted by the same poster. A number of criteria can be used to establish this. First, contents of the 
"From" field of the articles must be identical. Second, contents of other (some of them optional) header 
fields, such as "Path", "X-Trace", "NNTP-Posting-Host", etc should be identical or at least similar. 

3. Articles must have identical comment part of the subject. That is, the part of the subject that remains after 
removing file names, size information, file number in the post, CRC, etc. 

4. Articles were posted within a relatively short interval from each other. If article B follows article A, then 
time of posting B is not later than time of posting A plus some preset interval. For example, it is very rare 
that someone would post a part of collection and then continued posting the same collection after an hour 
interval. Most collections are posted in bulk, articles following each other within minutes or even seconds. 
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After a set of articles has been determined to be a collection using the criteria described above, the articles can be 
automatically downloaded, images extracted, indices built and posted. 

4.3 Third Aspect 

The system disclosed for the first aspect, has to be only slightly modified to enable posting and processing of 
advertisements. 

1. It must allow construction of images where some regions are advertising regions, such as banners. This 
does not represent a technical problem and can be done, for example, by inserting one or more 
advertisement banners in the images. 

2. It must allow association of the advertising regions in the image with URLs of the advertised Web sites. 
Introducing a slightly different type of image map records does this. Records of this type contain a URL 
instead of message identification information, preferably in format: 

rect <URL="url-texr"> coordinates 

3. Algorithm of processing of image map records has to be slightly expanded to accommodate for 
processing of advertisements. In particular, when the user clicks on an image and the newsreader finds 
that this region corresponds to a map record with a URL in it, the newsreader must know that the user 
wants to follow an advertisement link and react correspondency. Preferably, the newsreader will start a 
Web browser and direct it to the URL specified in the map record. 

4.4 Fourth Aspect 

For the purpose of counting visits, this invention requires a set up of a special Web site (or just of a script on an 
existing site) that redirects Web requests based on their parameters and at the same, time maintains counters of 
visitors redirected to particular sites. 

Suppose, the address of such a site is http://sendmeto.com/ and the name of the script that processes redirection 
requests is goto. The site has a database with containing URLs of target sites and associated visitor counters and 
possibly account (or profile) numbers. 

This script does the following: 

1 . Parse received request and extract its parameters. 

2. If the parameters contain a target URL: 

a. Find in the database a record with this URL. 

b. If such record does not exist, reply with an error message or just redirect the browser to the 
target URL. 

c. If the record exists, increment the associated visitor counter, update the record and redirect the 
browser to the target URL. 

3. If the parameters contain an account number: 

a. Find in the database a record with this account number. 

b. If such record does not exist, ignore the request or reply with an error message. 

c. If the record exists, increment the associated visitor counter, update the record and redirect the 
request to the associated URL. 

Having set up such redirection Web site and/or script, we can use for advertisement URLs that bring visitors to 
advertised sites not directly, but via the redirection site. We do this by generating URLs that pass the URLs of 
advertised sites as parameters to the processing script at the redirection site. 

For example, if we want to send visitors to http://mysite.com/, in our advertisement messages we use URL 
http://sendmeto.coin/goto?url=http://mysite.com/ 
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When user clicks on this URL (or their news client starts a Web browser with this URL in response to the user 
clicking on a banner), their request will start the "goto" script with the parameter "uri=http://my site.com/". 

The script will find a database record with this URL, increment its visitor counter, update the record and redirect 
the browser to http://mysite.com/ 

Thus, all visits to the advertised site that are generated by the advertisement post will be counted. 

The same effect can be achieved if we put original URLs in advertisement messages, but the newsreader program 
automatically sends them to the redirection site for redirection. 

For example, we put http://mysite.com/ in advertising message. When newsreader finds it, it automatically 
changes it to http://sendmeto.com/goto?url=http://raysite.com/ and starts a Web browser with this URL. 

5 Brief Description of Drawings 

Figure 1 shows a screen capture of a newsreader window - a part of a typical list of newsgroup messages. 
Figure 2 shows an index image. 

Figure 3 illustrates the way image map records establish associations between image regions and Usenet 
messages or Web sites. Note that there is an advertising banner at the top of the index image. 
Figure 4 shows data flow in a system with one index server, where produced indices are posted to the news 
server. Depending on implementation and configuration, they may be returned to the newsreader, bypassing the 
news server. 

1 . The user downloads list of available articles from the news server 

2. The user sends indexing request to the index server. 

3. The index server retrieves the articles to be indexed 

4. The index server builds indices and posts them to the news server. 
51- Optionally, the user downloads and previews the indices. 

6\ Optionally, the user downloads articles chosen based on the indices 

Figure 5 shows data flow in a system with multiple index servers, where produced indices are posted to ihe news 
server. Depending on implementation and configuration, they may be returned to the newsreader, bypassing the 
news server. 

h The user downloads list of available articles from the news server. 

2. The user sends indexing request to the index seiver. 

2a; The index server verifies that the articles have not been indexed yet and updates the global list of indexed 
articles. 

3. The index server retrieves the articles to be indexed. 

4. The index server builds indices and posts them to the news server. 

5. Optionally, the user downloads and previews the indices. 

6. Optionally, the user downloads articles chosen based on the indices. 
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6 The Claims Defining the Invention Are as Follows 

1. A method of coordinating the identification of media objects with their associated indices in a newsgroup of 
the Usenet, the method including the steps of: 

generating an index image (contact sheet) of the media objects, 

generating an image map of the index, the image map associating thumbnails in the index with messages 

carrying media items corresponding to the index thumbnails, 

generating and posting messages containing index images and their image maps. 

2. A method as claimed in claim 1 where index map entries are associated with thumbnails in the index image via 
coordinates of the thumbnails rectangles. 

3. A method as claimed in claim 1 where index map entries are associated with arbitrary image regions via 
coordinates of the image regions. 

4. A method as claimed in claims 1-3 where image map entries are associated with newsgroup messages by 
including message-ids of the messages in the map entries. 

5. A method as claimed in claims 1-3 where image map entries are associated with newsgroup messages by 
including an> combination of messages header fields in the map entries. 

6. A method as claimed in claims 1-5 where index image or any of the collection items may be split into several 
parts and each part posted in a separate message. 

7. A method as claimed in claims 1-6 where index is generated and posted with a new collection; 

8. A method as claimed in claims 1-6 where index is generated and posted for a collection that has been posted 
before and possibly by other poster. 

9. A method of downloading messages from the Usenet, the method including the steps of: 

receiving headers or only XOVER information of messages available for downloading, 
downloading the messages containing indices, 

presenting the indices to the user to make a decision regarding the downloading of associated objects, 
if the user wants to download an associated object, 

finding in the image map a record corresponding to the thumbnail selected by the user, 
finding and downloading the message that is associated with the image map record. 

10. A method as claimed in claim 9 where index map entries are associated with thumbnails in the index image 
via coordinates of the thumbnails rectangles. 

11. A method as claimed in claim 9 where index map entries are associated with arbitrary image regions via 
coordinates of the image regions. 

12. A method as claimed in claims 9-11 where image map entries are associated with newsgroup messages by 
including message-ids of the messages in the map entries. 

13. A method as claimed in claims 9-11 where image map entries are associated with newsgroup messages by 
including any combination of messages header fields in the map entries. 

14. A method as claimed in claims 9-13 where index image or any of the collectibn items may be split into 
several parts and each part posted in a separate message. 

15. A method as claimed in claims 9-14 where index was generated and posted with a new collection, 

16. A method as claimed in claims 9-14 where index was generated and posted for a collection that has been 
posted before and possibly by other poster. 
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17. A method of associating of a region of an image posted on the Usenet with a Usenet message or a Web site 
the method including the steps of: * ' 

generating an image map of the image, 

inserting in the image map a record containing coordinates of the image region to be associated, 
inserting in the same image map record an identifier of the object that the image region' is to be 
associated with, 

posting the image and the image map in a Usenet message. 

18. A method as claimed in claim 17, where a message-ID is used to identify a Usenet message. 

19. A method as claimed in claim 17, where a <subject, poster ED> pair is used to identify a Usenet message. 

20. A method as claimed in claim 17, where any combination of message header fields or their parts is used to 
identify a Usenet message. 

21. A method as claimed in claim 17, where a URL is used to identify a Web site. 

22. A method as claimed in claim 17, where any identifier is used to identify an addressable object. 

23. A method as claimed in claim 17, where the image and/or the image map are split in parts and posted in 
several messages. 

24. Using a method as claimed in claim 17 for creating and posting messages containing advertisement images 
regions of which are associated with URLs of advertised Web sites. 

25^ A method of processing messages containing advertisement images, regions of which are associated with 
URLs of advertised sites, the method including the steps of: 

downloading and presenting the message and the image to the user, 

if the user points to any point of the image and clicks or double c'licks on it, or expresses a request for 
action in any other established way, finding in the image map a record corresponding to the point, 
if the record is found and it contains URL of a Web site starting a Web browser and directing it to the 
target Web site. 

26. A method as claimed in claim 25 where the Web browser is directed not straight to the target Web site but 
first to a redirection site that will direct it to the target Web site. 

27. A method of counting visits generated by advertisement messages posted on the Usenet, the method including 
the steps of: ...... s 

setting up a redirecting Web site or only a script for visits counting, 

generating a URL pointing to the redirecting site and including information allowing to locate the 
advertised target site, 

when the user wants to access the target site, directing their browser first to the redirecting Web site, 
incrementing visitor counter maintained at the redirecting site, 
redirecting the user browser to the target Web site. 

28^ A method as claimed in claim 27 where the information allowing to locate the advertised target site is its 
URL. 

29. A method as claimed in claim 27 where the information allowing to locate the advertised target site is a key 
of a database record (e.g. account number) that has, or allows to establish, URL of the target Web site. 

30. A method as claimed in claims 27-29 where the URL pointing to the redirection site is generated and inserted 
into the advertising message by the poster or posting software. 

31. A method as claimed in claims 27-29 where the user news client automatically generates the URL pointine to 
the redirection site based on the original URL found in the advertisement message. 
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32. A method and system for providing on request previews (metadata descriptions, indices) of multimedia 
objects posted on the Usenet, the system consisting of: , 

• A functioning news server; 

• A user NNTP client application (newsreader); 

• An index server; 

The method including the steps of: 

• Using the news reader, choosing a set of articles to be indexed; 

• Forming index request and submitting it to the index server; 

• Downloading the articles by the index server, 

• Constructing indices/previews by the index server and posting them to the news server. 

33. A method and system for providing on request previews (metadata descriptions, indices) of multimedia 
objects posted on the Usenet, the system consisting of: 

• A functioning news server; 

• A user NNTP client application (newsreader); 

• An index server; 

The method including the steps of: 

• Using the news reader, choosing a set of articles to be indexed; 

• Forming index request and submitting it to the index server; 

• Downloading the articles by the index server; 

• Constructing indices/previews by the index server and either posting them to the news server or sending 
them back to the user who requested them, or both, depending on implementation and configuration. 

34. A system and method as in claim 32 where index server functions are built in into the news server. 

35. A system and method as in claim 33 where index server functions are built in into the news server. 

36 A system and method as in claims 32 and 34 where the index server maintains a list of articles indexed 
before, in order to avoid repetitive indexing. 

37 A system and method as in claims 33 and 35 where the index server maintains a list of articles indexed 
oetore, m order to avoid repetitive indexing. 

lervts ySt * m meth ° d ^ ^ ClaimS 32 34 WhCre SyStem C0RSiStS ° f mU,tipIe neWS Servers ^ index 
39. A system and method as in claims 33 and 35 where the system consists of multiple news servers and index 

j c rvc rs _ 



40. A system and method as .n claims 32, 34 and 38 where one or more of the index servers maintain global lists 
of indexed articles m order to avoid repetitive indexing. Other servers verify requests with them before 
processing. The servers maintaining the lists exchange updates as soon as new articles are added to the lists. 

36. A system and method as in claims 33, 35 and 39 where one or more of the index servers maintain global lists 
of indexed articles in order to avoid repetitive indexing. Other servers verify requests with them before 
processing. The servers maintaining the lists exchange updates as soon as new articles are added to the lists. 

and , me * od "■J" ? aims u 32 ' 33 and 35 where each index server is specialised and dedicated to 
creatmg indices only for a particular subset of newsgroups. 

38. A system and method as in claims 33, 35 and 39 where each index server is specialised and dedicated to 
creating indices only for a particular subset of newsgroups. 

39 A method for identifying posted image collections, in order to index them automatically. The method 
subject comment part and have been posted within a reasonably short time interval from each other 
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